As the subject of this post suggests, this is with regard to testing partitions. Although I have used DOORS for a few years, I never really found the need to dabble with partitions in DOORS. It seems to offer some very useful functionality and hence I figured I should test it. I tried creating a partition in DOORS on my "home" database. I set the access rights for the partition to be "REad only" for the AWAY database. I transferred the partition file to another machine and then imported it into the AWAY doors database and the import worked just fine. Obviously, I could not edit anything in there since I had set the access rights on the partition to be "Read only". When I tried returning the partition, I browsed to the original location of the partition file on the computer and did not try renaming the partition file. When I go ahead and do this, I realize that the partition file can no longer be found on the local hard drive. Have any of you encountered this? Any thoughts on why this might happen? Any input is highly appreciated. Thank you in advance.
Regards,
Pranav
PranavC - Sat Mar 28 16:51:27 EDT 2009 |
|
Re: Testing partitions in DOORS llandale - Mon Mar 30 15:09:46 EDT 2009
Not sure you need to 'return' a read-only partition from the Away database nor 'rejoin' it back into the Home database. It seems to me that if you send a read-only partition to an away database (perhaps the sub-system requirements to the vendor, who figure to modify the P-Specs), you can immediately 'delete' that partition in the Home database, then proceed to work on the data. Likewise the Vendor can send the Contractor a read-only partition of its P-Specs, and then delete it right away. Thus, the Vendor sees the read only Subsystem spec in a Partition, the Contractor sees a read-only P-Spec in a Partition, but the original Partitions are gone.
We played with partitions years ago and it was a disaster, and we never looked back at it. Perhaps they've fixed the serious bugs.
Anyway, looking at DOORS Help it appears there is a Partition file, a Return File, and a Synchronize file. When you Rejoin, it expects a Rejoin file. I presume these files have different extentions, and that's why you don't see the Partition file when attempting to Rejoin.
>Louie
|
|
Re: Testing partitions in DOORS; 'recover' llandale - Mon Mar 30 15:12:13 EDT 2009 llandale - Mon Mar 30 15:09:46 EDT 2009
Not sure you need to 'return' a read-only partition from the Away database nor 'rejoin' it back into the Home database. It seems to me that if you send a read-only partition to an away database (perhaps the sub-system requirements to the vendor, who figure to modify the P-Specs), you can immediately 'delete' that partition in the Home database, then proceed to work on the data. Likewise the Vendor can send the Contractor a read-only partition of its P-Specs, and then delete it right away. Thus, the Vendor sees the read only Subsystem spec in a Partition, the Contractor sees a read-only P-Spec in a Partition, but the original Partitions are gone.
We played with partitions years ago and it was a disaster, and we never looked back at it. Perhaps they've fixed the serious bugs.
Anyway, looking at DOORS Help it appears there is a Partition file, a Return File, and a Synchronize file. When you Rejoin, it expects a Rejoin file. I presume these files have different extentions, and that's why you don't see the Partition file when attempting to Rejoin.
>Louie
...err... you should 'recover' the just-sent Partition, not 'delete' it as I said originally.
|
|
Re: Testing partitions in DOORS SystemAdmin - Tue Mar 31 01:37:02 EDT 2009 llandale - Mon Mar 30 15:09:46 EDT 2009
Not sure you need to 'return' a read-only partition from the Away database nor 'rejoin' it back into the Home database. It seems to me that if you send a read-only partition to an away database (perhaps the sub-system requirements to the vendor, who figure to modify the P-Specs), you can immediately 'delete' that partition in the Home database, then proceed to work on the data. Likewise the Vendor can send the Contractor a read-only partition of its P-Specs, and then delete it right away. Thus, the Vendor sees the read only Subsystem spec in a Partition, the Contractor sees a read-only P-Spec in a Partition, but the original Partitions are gone.
We played with partitions years ago and it was a disaster, and we never looked back at it. Perhaps they've fixed the serious bugs.
Anyway, looking at DOORS Help it appears there is a Partition file, a Return File, and a Synchronize file. When you Rejoin, it expects a Rejoin file. I presume these files have different extentions, and that's why you don't see the Partition file when attempting to Rejoin.
>Louie
I've played around a fair bit with so called "Read Only" partitions as they are a handy way to create a sanitised snapshot copy of a project for a customer or supplier that also has DOORS.
When creating a partition on a HOME DB where all modules are defined to have Read-only access on the AWAY DB, the HOME DB realises that this partition can never ever be returned\rejoined so no modules within that project on the HOME DB are locked up and the HOME DB doesn't even bother to record the exported partition file under the "Exported Partitions" tab. So, beyond importing the partition file into the AWAY DB, the partition file in effect becomes worthless.
Paul Miller
Specification Practices Specialist
EuroCyber
Melbourne, Australia
|
|